feat: Remove Explore URLs and make the normal URLs public #2632
Conversation
fixed sidebar link not working fixed sidebar link target hide cookbooks header when there are none
|
I changed the routes as discussed above (I went with I realized the metadata injection was broken in prod since the FastAPI SPA was manually constructing those routes. I'm pretty sure I fixed it, but I need to verify with a prod docker build (hopefully I'll have time later tonight, if not tomorrow, unless you get the chance to confirm) |
|
Not sure if I'm just doing something wrong or I broke something but running the docker compose locally doesn't work. I'm getting: |
|
So what does this now make the public url for viewing all recipes? I had a shortcut on my iPhone for that page, which no longer works, and it seems this is the reason. Is there still a link to view all recipes, or does public access only work for specific recipes like the example above? On a somewhat related note, the old link was a redirect, and the redirected-to url was not publicly accessible directly, so I had to take the janky step of turning off my internet connectivity to save the public url to my iPhone home screen. Is that something that has changed with this update? If not, I can submit a feature request. I find that it's nice to be able to share your catalogue with family and friends without requiring them to log in. But more selfishly, it's just far easier to have the public read-only link quickly accessible from my phone for those times when your hands are covered in food. |
The same URL you use to browse while logged-in. There's no special URL anymore. So, if you navigate to your list of recipes, copy that link, log out, and try going to that link again. You'll see all your recipes, but you won't be logged-in. |
|
Thanks. I can confirm that using It's still creating an issue with iOS shortcuts, though, because when I try to add that page to my home screen it instead creates a link to |
There is a workaround that you could use today by creating a redirect rule if you have mealie behind a load balancer/reverse proxy. See the POC on this feature request. |
I'm not familiar with iOS shortcuts, but yeah, that seems weird
FYI I have a PR in for this now: #2772 |
|
Re the iOS shortcuts issue, can you provide specific detail for how that is being setup? The ideal would be a screen recording of start to finish. That might allow us to understand it better. (I'm wondering if it might be using the PWA or something) |
|
Sure.
|
|
Annoying you can't edit the url. Are you comfortable building a Dev instance? I wonder if this is the cause of the url being what it is: https://github.com/mealie-recipes/mealie/blob/mealie-next/frontend/nuxt.config.js#L336 I'm not sure we realistically have much scope to change that though. |
#2772 should at least fix this for users only using a single group (or who want all public users to be directed to the default group). This would effectively make the "default group" also the "iOS Shortcut" group. No idea if such a thing exists to have multiple start urls. |
|
Yeah, I don't know enough about iOS shortcuts to know how it works. But on RC1.1, you could get it to work using the offline method I described above. And yes, 2772 should do what I'm looking for. It's one extra click if you actually do want to log in, but that's fine for my purposes. I'll wait for it to get merged. I'm sure I could figure it out, but I've never built a dev instance. |
What type of PR is this?
(REQUIRED)
What this PR does / why we need it:
(REQUIRED)
This removes the frontend explore pages and adapts the "private" pages to allow public access (unless things are marked as private, of course).
To accomplish this, all pages (with a few exceptions, see below) now have the group slug in their URL. So, for example:
https://my-mealie-domain.com/recipe/pasta-fagiolihttps://my-mealie-domain.com/home/recipe/pasta-fagioliI'm not too horrible of a person, so any time you reach the 404 page and you're logged in, we try to redirect you to
.../${groupSlug}/${whereverYouWereTryingToGo}in an attempt to preserve existing links. This usually works, though there are bound to be edgecases. In the above example, for instance, the invalid URL will redirect you to the valid URL (if you're logged-in, otherwise we don't know which group to put you in).The only non-group-slug-dependent pages are the following:
As a side-effect, all of the public URL copying (on recipes and on your user profile page) has been removed, since it's useless now. The recipe share functionality is still there, though, since that allows private access.
While I'm already messing with the sidebar, I noticed the cookbook secondary header wasn't working (hence #2679) so I got that working again. I also conditionally hid it if you don't have any cookbooks yet.
As an added bonus to this already-too-big-for-my-own-good PR, I tweaked the
loggedInrefs throughout the app to check if the logged-in user belongs to the group. This way a logged-in user can stay logged-in while visiting other groups (you can't really do anything special, you just aren't forced to log out to view other groups now).This leads to some weird scenarios if you try manually adjusting your URL (e.g. if you go to
.../not-my-group-slug/shopping-listsyou will be successful, but it's still going to show you your group's shopping lists). Fixing that would probably take 10x more work than the work done on this PR, since the app was originally built with the assumption that you're always in your own group, but there is no way through the UI to get to this weird state (that I know of, anyway), which I think is adequate.Another option is to instead keep user and group pages within their own spaces<-- I did this. I moved cookbooks and the recipe timeline under.../${groupSlug}/recipe/...to accommodate this.Which issue(s) this PR fixes:
(REQUIRED)
Closes discussion #2679
Special notes for your reviewer:
(fill-in or delete this section)
Tons of things were changed to get this to work, but it's not too much of a mess. Thankfully all the lower-level stuff didn't need much/any modification. I had to do some funky stuff with the routes/layouts to inject your group slug when you log in (since the login page is group-agnostic). It probably needs a few eyes on it to make sure nothing too jank is happening.
Testing
(fill-in or delete this section)
Unfortunately, this PR touches pretty much every page and most of the main components, and none of it affects anything with test coverage, so all testing is manual. I did a lot of poking around and global searching in VSC for patterns likely to break, but there are bound to be edge cases.
Release Notes
(REQUIRED)